Questioning the Continued Lack of a Focus on Cybersecurity

Why are we still doing this dance? Going back more than a decade, medical device manufacturers were first “strongly encouraged” and now “required” by the FDA to digitally secure new devices. However, the position of the majority of manufacturers is to try to ignore this directive. When finally forced into addressing security, it typically only occurs after they have received a hold letter from the agency.

It’s similar to dealing with a medical insurance provider: “Deny, Delay, Defund.”

Over my long career of developing medical devices, I have participated in many “non-essential” activities leading up to providing a release candidate. Among these have been: 

• User experience (UX), both formative and summative
• System-level requirements
• Product-level requirements
• Detailed design requirements
• Interface control documents (ICD)
• Hazard analysis
• Failure mode, effects, and criticality analysis (FMECA)
• V&V testing
• Instructions for use (IFU)
• Host of UML and SysML diagrams
• Design controls
• Configuration controls
• Weeks of effort to put together a pre-market submission package

In the end, all that was really needed was good hardware and software engineers.

Right now, most developers should be screaming about a lack of quality, not knowing what they are building, not meeting user needs, etc. All of those are legitimate concerns; I don’t view those activities as “non-essentials.”

My point, however, is that we add these other activities to meet the needs of everyone who may use this medical device, even if they don’t know it. Does a patient with a cardiac pacemaker implanted in their chest question the completeness of the hazard analysis, or the accuracy of an ICD? Would the manufacturer perform these activities if not required by a regulatory agency? Probably not.

So why, given all this existing overhead, is cybersecurity so often ignored, delayed, and denied?

The Cybersecurity Omission

Originally, I thought the seemingly deliberate attempt to circumnavigate cybersecurity was due to a lack of security education on the part of developers. I even went so far as to create an extensive online training program for medical device developers. For the few students who took it, it achieved the desired results, but that was a very small group compared to how many people are developing software-enabled medical devices.

Likewise, I co-wrote the first book on medical device cybersecurity (with the same goals in mind), which has sold well and is now in its second edition. Still, I routinely encounter medical device developers who have ignored all advice to the contrary and tried to get a medical device to market without any security.

No manufacturer wants delays in reaching the market; the most important requirement when developing a medical device is the date of shipping. Woe be unto them that even contemplate violating some capricious date set by managers and accountants.

Yet, everyone seems fine with ignoring cybersecurity. How can this approach make sense to anyone?

FDA Demands Proof

Premarket submissions have become more structured under eSTAR, but there is still some flexibility in how a manufacturer submits the required content, except for cybersecurity. 

The FDA has done us a huge favor in being very exacting about what documents/artifacts are required, and what the content should be in those documents. In some cases, the agency has gone so far as specifying the structure of those documents. Uncertainty causes delays: questions such as “Did I do enough?” and “Was this topic needed?” are all removed by the FDA’s approach. This means we can provide the agency with exactly what it wants to see, improving the chances of meeting our time-to-market deadline. 

This should be viewed as a good thing. So I’m left to ask again why cybersecurity continues to be routinely ignored by manufacturers until it can’t be ignored.

A submission to the FDA that is deficient in cybersecurity will not only delay market approval but also damage the manufacturer’s reputation in the agency’s eyes. This may result in any subsequent supplemental submission to correct cybersecurity issues being much more heavily scrutinized by the agency for both intentional abuse and general ignorance of how cybersecurity is to be performed. It is much faster to present a submission package that demonstrates competence in all aspects, including cybersecurity.

Unfortunately, it’s too late to consider this. A submission without cybersecurity has been made and you’ve now received a 20-page hold letter. Congratulations, you now have 180 days to redesign your system, document it, and conduct cybersecurity testing. This “bolted on” approach to cybersecurity will cost more, increase the cost of your medical device, and may require substantial redesign (such as changes to CPUs and microcontrollers). It will also be less effective as a mitigation and will usually be more intrusive/burdensome for end users. All of this simply because cybersecurity was ignored when development started.

While you may think this is “regulatory overreach” by the FDA, I have some news for you. The rest of the world is even more aggressive in enforcing cybersecurity, such as the EU’s MDR and CRA regulations, where the attitude has shifted from “best practice” to “market access regulations.” You now have software liability for your products in the EU. Your poorly designed product was the entry point for a hacker into an organization where significant financial losses occurred. You are now liable for this.

Arguing the Point

A final comment is to those who acknowledge cybersecurity is required but then try to neuter what is performed by their own erroneous inclusion of “risk-based decision making.” Whenever I see that phrase, I know exactly what I am dealing with. It’s typically someone who would rather spend months arguing about the likelihood of a cybersecurity incident than simply implementing mitigations. 

About eight years ago, I was on-site at a manufacturer’s facility. We were in a meeting, and the head of software development was arguing that creating a specific mitigation was impossible (not just that it would take too long to implement, but impossible). The vice president of engineering, a very intelligent man, was pushing back during the meeting, arguing with the software head, which eventually evolved into yelling. Meanwhile, I was trying to become invisible and shrink into my chair as this was going on. As the battle ensued, I opened my laptop and wrote the “impossible” software to mitigate the vulnerability in question. 

It took much less time to simply fix the potential issue than to argue about it.

Once I showed my solution to the head of software, the steam was taken out of his argument, and the meeting ended. This same person later became a huge proponent of security (go figure).

Conclusion

I don’t know why so many still want to pretend they don’t have to address cybersecurity in their medical device systems, but it is causing real harm to development projects. Start including cybersecurity from the first day of the development project. If you don’t have someone on staff with experience, reach out to someone who does. There are a few of us whose job it is to help you include cybersecurity in your new medical device.

MORE FROM THIS AUTHOR: FDA’s Top 10 Cybersecurity Reasons for a Hold Letter

Christopher Gates is the founder and CEO of arsMedSecurity, a medtech cybersecurity consulting firm. He is a recognized thought leader in medical device cybersecurity and the current co-chair for H-ISAC’s MDSC. Gates has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, and Bluetooth SIG.